Solution Architecture Document Template <Project Name>	Project #: Document Version:	<Project #> 0.1
Author:	<Name>
Document Status:	Initial Draft
Published Date:	<Date>

Revision History

This table lists revisions of this document.

Date	Version	Description	Author
<mm/dd/yyyy>	0.1	Initial Draft	<Name>

Table of Contents

Table of Figures	2

1.	Introduction	2

1.1	Purpose	2

1.2	Stakeholders	2

1.3	Contributors	2

1.4	Scope of the Document	2

1.4.1	In Scope	2

1.4.2	Out of Scope	2

1.5	Definitions, Acronyms and Abbreviations	2

1.6	References	2

2.	Architecture Goals	2

2.1	Problem Background	2

2.2	Current State (As-Is) Assessment	2

2.3	Business Requirements	2

2.3.1	In Scope	2

2.3.2	Out of Scope	2

2.4	High Level Business Process	2

2.5	Vendor Packages and Frameworks	2

2.5.1	Proprietary Demands	2

2.6	Architecturally Significant Use Cases	2

2.7	Architectural Drivers	2

2.7.1	Non-Functional Requirements	2

2.7.2	Assumptions	2

2.7.3	Constraints	2

2.7.4	Opportunities	2

2.7.5	Risks	2

2.7.6	Decisions	2

3.	Architecture Overview	2

3.1	Enterprise Architecture	2

3.2	Design Patterns	2

3.3	Solution Overview	2

3.3.1	Conceptual View	2

3.3.2	Logical Component View	2

3.3.3	Data Context View	2

3.3.4	Network View	2

3.4	New Applications	2

3.5	Candidates for Enterprise Services	2

3.6	Solution Interfaces	2

3.6.1	<Interface #1> Interface	2

3.6.1.1	Functional Description	2

3.6.1.2	Interface Diagram	2

3.6.1.3	Attributes	2

3.6.2	<Interface #2> Interface	2

3.6.2.1	Functional Description	2

3.6.2.2	Interface Diagram	2

3.6.2.3	Attributes	2

3.7	Impact on Other Applications	2

3.8	Architectural Quality	2

3.8.1	Internationalization	2

3.8.2	Time Zone Support	2

3.9	Information Architecture	2

3.9.1	Data Security	2

3.9.2	Authentication	2

3.9.3	Authorization	2

3.9.4	Auditing	2

4.	Infrastructure Architecture	2

4.1	Infrastructure Patterns	2

4.2	New Infrastructure	2

4.2.1	Logical Design	2

4.3	Infrastructure Environments	2

4.3.1	Development	2

4.3.2	Test	2

4.3.3	QA	2

4.3.4	Production	2

4.3.5	Disaster Recovery (DR)	2

4.4	Infrastructure Catalog	2

5.	Production Support	2

5.1	Point of Failure Analysis	2

5.2	System Reliability	2

5.3	System Monitoring	2

5.4	System Recovery	2

5.5	Disaster Recovery	2

5.6	Portability	2

5.7	Support and Maintenance	2

6.	Appendix	2

Table of Figures

Figure 1 – Current State Diagram	2

Figure 2 – High Level Business Process	2

Figure 3 – Use Case Diagram	2

Figure 4 – Conceptual View	2

Figure 5 – Logical Component View	2

Figure 6 – Data Context View	2

Figure 7 – Network View	2

Figure 8 – <Interface #1> Interface Diagram	2

Figure 9 – <Interface #2> Interface Diagram	2

Figure 10 – Infrastructure Logical Design Diagram	2

Figure 11 – Development Environment Diagram	2

Figure 12 – Test Environment Diagram	2

Figure 13 – QA Environment Diagram	2

Figure 14 – Production Environment Diagram	2

Figure 15 – Production Environment Diagram	2

Introduction

[The introduction provides an overview of the entire Solution Architecture Document. It includes purpose, scope, definitions, acronyms, abbreviations, references, and structure of the Document.

FNFG’s Solution Architect will typically perform the following major steps in order to define the application architecture and high level design, and each time an activity is performed, a specific section of this document is enriched accordingly.

Architectural Activity	Relevant Sections in the document
Step 1: Start the Introduction section to the extent possible. Come back to this section throughout the Planning phase to complete.	1. Introduction
Step 2 through 7: Based on information in the Project Charter and other available business related documents, provide a high level overview of the project and include other elements of interest with emphasis on the architectural relevance as applicable.	2. Architecture Goals 2.1 Problem Background
Step 3: Define and document current solution state including architectural layout if applicable. This section may have sub-sections depending on the extent and importance of the current solution to be upgraded or replaced.	2.2 Current State (As-Is) Assessment
Step 4: Identify architecturally relevant business requirements and processes from business related documents (BRD, etc).	2.3 Business Requirements
Step 5: Describe any external packages and frameworks that are part of the solution.	2.4 Vendor Packages and Frameworks
Step 6: Identify architecturally significant use cases (Functional Requirements) from the list of use cases defined by the business analyst.	2.5 Architecturally Significant Use Cases
Step 7: Identify the architectural drivers that govern the high level architectural design of the solution, based on the project vision, supplementary specifications and other project documents.	2.6 Architectural Drivers (NFRs, Assumptions, Constraints, Opportunities, Risks, Decisions)
Steps 8 through 17 pertain to the Future (To-Be) state. Completing these steps is an iterative process.	3. Architecture Overview
Step 8: Identify any enterprise architecture principles and patterns that govern the solution.	3.1 Enterprise Architecture 3.2 Design Patterns
Step 9: Define the high level candidate architecture for the new solution. This activity may be performed multiple times throughout the Planning phase. This section contains all the different architectural views of the solution.	3.3 Solution Overview
Step 10: Describe any new application to be developed as part of the solution, if applicable.	3.4 New Applications
Step 11: Identify any suitable candidates for the Enterprise Service Bus (ESB), if applicable.	3.5 Candidates for Enterprise Services
Step 12: Describe any manual, user and/or system interfaces that are part of the solution as applicable. If extensive specification is required, then reference a separate Interface Design Document for each such interface.	3.6 Solution Interfaces (reference to IDD)
Step 13: Identify how the solution impacts other applications in the enterprise, if applicable.	3.7 Impact on Other Applications
Step 14: Describe any security, authentication, authorization and other non-functional aspects of the solution, if applicable.	3.8 Architectural Quality
Step 15: Document the information architecture as it applies to the solution. Information for this section is provided, at least in part, by the Information Architect and Information Security personnel.	3.9 Information Architecture
Step 16: Document the infrastructure architecture with proposed hardware and system software for the solution. This chapter is typically the responsibility of the Infrastructure Architect.	4. Infrastructure Architecture
Step 17: Document how production support will be handled for the solution. This chapter is typically provided by the Solutions Delivery Support team.	5. Production Support

All this text within brackets and other blue text throughout the document, including the table above, serves as guidance in the template only and should be removed in the actual published document.]

Purpose

[This section defines the purpose of the Solution Architecture Document in the overall project documentation and briefly describes the structure of the document. The specific audiences for the document are identified, with an indication of how they are expected to use the document.]

This Solution Architecture Document provides a comprehensive architectural overview of the proposed solution for the <Project Name> project. It presents a number of different architectural views to depict various aspects of the solution, with the intent to convey a high level picture of the technical environment of the solution as well as its place and interaction with other systems in the enterprise. A Current State Assessment is included, if applicable, to provide a framework and continuity reference for solutions that will replace current system(s).

Even though the document's primary purpose is to provide a platform for detailed design activities by technical analysts and developers, it can be consumed in various levels of detail by the business community as a complement to functional requirements and specifications documents.

Stakeholders

[Individuals with a specific and accountable interest in this project are identified in this section. The term “Stakeholder” refers to individuals representing a role or area of responsibility within the organization with a ‘stake in’, i.e. dependent on or affected by, the solution and that in one way or another has a participating interest in the project. Solution Architect should modify the contents of the table below as dictated by the project needs.]

This table lists individuals with a specific and accountable interest in this solution.

Stakeholder	Role / Area	Stakeholder’s Interest / Concern
Business Sponsor	Cost. On-time delivery. Usability and quality.
Project Manager EPMO Project Manager TPMO	Development cost and schedule. Basis for work breakdown structure.
Enterprise Architect	Architectural governance
Quality Assurance	Testability. Quality & performance validation.
Subject Matter Expert (SME)	Accuracy of captured information.
Development	System design / development. Modifiability. Testability. Ease of integration. Interface specifications.

Note: Not a complete list of everybody interested and/or involved in the project. See meeting notes on the project site for details and list of interested parties.

Contributors

[Individuals with a contributing role in completing this document are identified in this section. The term “Contributor” refers to individuals providing input in one form or another relative to the contents of this document. Solution Architect should modify the contents of the table below as dictated by the project needs.]

This table lists individuals contributing to the content of this document.

Contributor	Role / Area	Contribution	Content
Solution Architect	Author, Reviewer	Section 1 - 3, All
Information Architect	Author, Reviewer	Section 4, All
Infrastructure Architect	Author, Reviewer	Section 5, All
Solution Delivery Support	Author, Reviewer	Section 6, All

Scope of the Document

[Provide a brief outline of the project and how it relates to this document.]

In Scope

[Describe in-scope statements in context of this document.]

The overall solution architecture from a conceptual, logical and physical perspective, based on the scope defined in Business Requirements – In Scope section below.

Out of Scope

[Describe out of scope statements in context of this document.]

Functionality identified in the Business Requirements – Out of Scope section below is not part of this project and therefore not covered in this document. Anything not specifically defined as In-Scope is considered to be Out of Scope.

Definitions, Acronyms and Abbreviations

[Explain the terms, acronyms and other abbreviations used in the document.]

For any unidentified terms or acronyms please see the ARB Enterprise Glossary.

This table lists terms, acronyms and other abbreviations used in this document.

Term	Definition
FNFG	First Niagara Financial Group

References

[Provide a complete list of all documents from which information has been gathered and included in this document, whether actually referenced in the text or not. Identify each document by title, report number (if applicable), date, and publishing organization if applicable. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document. Include links where applicable to project related documents, use case specifications etc.]

<Project Name> Project Charter:

<link here>

<Project Name> Architecture Profile:

<link here>

<Project Name> Business Requirements Document:

<link here>

Architecture Goals

[This chapter describes the project and includes scope, business requirements, business processes and other elements of interest, with emphasis on the architectural relevance, to serve as the basis for the new solution.]

Problem Background

[Provide a brief overview of the project and the business opportunity or problem it is intended to solve. Information required in this section may be sourced from other project documents, such as vision, charter and requirements documents. Link to content where appropriate. Translate and summarize architecturally significant content as needed.]

Current State (As-Is) Assessment

[Provide a brief description of the current solution from an architectural point of view. The Infrastructure Architect’s Engineering Design document typically can be sourced for this content. Add sub-sections with architectural diagrams as appropriate and relevant to the To-Be solution. When possible, provide links to documents within the enterprise that help define the existing state. If the To-Be solution is “net new” and does not enhance or replace an existing solution, then enter “N/A”.]

Figure 1 – Current State Diagram

Business Requirements

[Describe the business requirements that are architecturally significant and have an impact on the overall solution.]

Architecturally significant In Scope and Out of Scope statements are listed in their respective sections below.

In Scope

[Describe specific business related elements of architectural significance that are in scope.]

Out of Scope

[Describe specific business related elements of architectural significance that are out of scope.]

High Level Business Process

[Outline business process(es) of architectural significance that is/are the basis for the solution.]

Figure 2 – High Level Business Process

Vendor Packages and Frameworks

[List and describe any vendor systems (ASP or in-house), open-source or proprietary frameworks and other external hardware and software products that are part of the solution.]

Proprietary Demands

[Describe any dependencies as a result of using vendor packages and frameworks as part of the solution.]

Architecturally Significant Use Cases

[This section includes a use-case diagram and/or table containing those use cases, from the use-case model if applicable, that represent a significant and central functionality of the final solution, or those that have a large architectural coverage, exercise many architectural elements or illustrate a specific point of the architecture. Link to content where appropriate. Translate and summarize architecturally significant content as needed. For each use case that represents a unique flow, a Sequence Diagram should be provided. Business Analysts should provide the information for this section. If no uses cases exist, then the Solution Architect should provide technical use cases.]

The following business requirements / use cases specified in the Business Requirements Document (BRD) have an architectural impact:

Ref ID	Description	Architectural Impact	Type
<Ref ID>	<Type>

[The <Ref ID> contains reference to requirements / use cases in the BRD as applicable. Type can be “User Interface”, “System Interface”, “System Process” or other categorization depending on solution.]

Figure 3 – Use Case Diagram

Architectural Drivers

[This section defines the overall architectural framework for the solution that will provide guidance and boundaries in the design of the solution. Also include any architectural dependencies identified as part of a vendor solution, as outlined in SOW or other documents. This section should be revisited throughout the Planning Phase to ensure completeness.]

Non-Functional Requirements

[Provide descriptions of the non-functional requirements or quality attributes that will govern the design of the solution. For a general definition of the quality attributes, see FNFG’s Architecture Glossary (TBD).The table below is a sample list of architectural quality attributes and should be modified as needed or necessitated by the project and its size and/or complexity. The information typically can be sourced from business related project documents. This section is the responsibility of the Solution Architect but should be jointly reviewed and edited with the Infrastructure Architect as well as the business community.]

This table lists architecturally significant non functional requirements.

NFR / Quality Attribute	Description / Specific Goals	Value / Range
User base	Total number of users. Total number of concurrent users.
Transaction volumes	Average. Peak.
Data volumes	Local. Global. Shared.
Performance	Response time. Calculation time.
Availability	Operating hours. Maintenance hours.
Reliability	Uptime. Downtime. Recovery Time Objective (RTO). Recovery Point Objective (RPO).
Usability	Mouse minimal. Screen size.
Scalability	Expected growth in number of users. Expected growth in volumes.

Assumptions

[This table lists architecturally significant design assumptions, where AA stands for Architectural Assumption.]

This table lists architecturally significant design assumptions.

ID	Title	Details
AA01
AA02

Constraints

[This table lists architecturally significant design constraints, where AC stands for Architectural Constraints. Design constraints are immutable external directives that place limitations and boundaries on the overall design and must be factored into all design options. Detail any enterprise standard technologies this project is required to utilize and how they impact (L M H) the solution. Also, list any vendor mandated technology with reason for that if known and include a reference to source documentation for the constraint. This section is the responsibility of the Solution Architect but should be jointly reviewed and edited with the Infrastructure Architect.]

This table lists architecturally significant design constraints.

ID	Title	Details	Impact
AC01
AC02

Opportunities

[This table lists identified architecturally significant design opportunities, where AO stands for Architectural Opportunity. These are not a summary of all project opportunities, but rather those that may present benefits to the architecture as a whole. Include here any new services that may be good candidates for Enterprise service re-use. Specify the perceived value (L M H) of the benefit.]

This table lists architecturally significant design opportunities.

ID	Title	Description/Benefits	Value
AO01
AO02

Risks

[This table lists identified architectural risks, where AR stands for Architectural Risk. These are not a summary of all project risks, but rather those that may have a material impact on the architecture and the design of the solution. Once the design has been approved, these risks can be transitioned into project risks. Specify the expected likelihood (Factor) and Impact (L M H).]

This table lists architecturally significant design risks.

ID	Title	Description / Mitigation	Factor	Impact
AR01
AR02

Decisions

[This table lists architecturally significant decisions made that has a material impact on the design of the solution, where AD stands for Architectural Decision. Available alternative options should also be included with rationale for the resulting decision. This section is the responsibility of the Solution Architect but should be jointly reviewed and edited with the Infrastructure Architect. More detailed information around the infrastructure design decisions will appear in the Infrastructure Architect’s Design Document.]

This table lists architecturally significant design decisions.

ID	Decision	Description / Rationale
AD01
AD02

Architecture Overview

[This chapter represents the core part of the document and is intended to provide a complete high level architectural view of the solution.]

Enterprise Architecture

[List and describe any architectural principals that govern this solution.]

Design Patterns

[List any architectural design patterns utilized in this solution. Provide links to common patterns as applicable. Explain in detail if a new pattern is discovered as part of this application architecture design.]

Solution Overview

[This section introduces the high level solution in an architectural context as governed by the architectural drivers and is depicted through various views.]

Conceptual View

[This section depicts the solution in a conceptual architecture diagram.]

Figure 4 – Conceptual View

Logical Component View

[This section depicts the solution in a logical component diagram.]

Figure 5 – Logical Component View

Data Context View

[This section depicts the solution in a data context diagram.]

Figure 6 – Data Context View

Network View

[This section depicts the solution in a network centric diagram.]

Figure 7 – Network View

New Applications

[Describe any new application to be designed, built and implemented as part of the solution.]

Candidates for Enterprise Services

[Identify any functionality that has the potential to be added as a member of the Enterprise Service Bus (ESB) service library.]

Solution Interfaces

[Identify and describe any interface that is part of the solution. When warranted, due to size and/or complexity of an interface specification, create a separate Interface Design Document (IDD) and make a reference, preferably by a link, in this section to that document. Add a sub-section for each additional interface as needed.]

<Interface #1> Interface

[Provide a brief overview, including purpose, of the interface.]

Functional Description

[Describe in detail the functionality of the interface.]

Interface Diagram

[Provide a visual representation of elements and their interactions in the interface.]

Figure 8 – <Interface #1> Interface Diagram

Attributes

[Provide a descriptive list of non-functional aspects of the interface, such as timings, frequencies, volumes, performance expectations, etc.]

<Interface #2> Interface

[Provide a brief overview, including purpose, of the interface.]

Functional Description

[Describe in detail the functionality of the interface.]

Interface Diagram

[Provide a visual representation of elements and their interactions in the interface.]

Figure 9 – <Interface #2> Interface Diagram

Attributes

[Provide a descriptive list of non-functional aspects of the interface, such as timings, frequencies, volumes, performance expectations, etc.]

Impact on Other Applications

[Describe how this solution impacts other applications. Those applications should be represented in an Application Environment Diagram. If multiple applications are impacted then each should be documented separately in a subsection of this section. If none, enter “N/A”.]

Architectural Quality

[Specify any non-functional attributes of the solution that are not already defined in section 2.6.1 Non-Functional Requirements]

Internationalization

[Specify any considerations regarding support for multi-language, multi-currency, etc.]

Time Zone Support

[Specify any considerations regarding support for multiple time zones]

Information Architecture

[Describe any information related attributes, components and processes that are part of the solution. Information for this section is typically provided by Information Architect and Information Security personnel.]

Data Security

[Describe how data is kept secure in flight and at rest.]

Authentication

[Describe how access to the system is protected.]

Authorization

[Describe how different persons and/or groups of persons are entitled to access different parts and/or functionality of the system based on levels, roles, etc.]

Auditing

[Describe how activities are logged in the system.]

Infrastructure Architecture

[This chapter represents the entire infrastructure required to support the solution and generally it is the responsibility of the Infrastructure Architect to provide, in whole or in part.]

Infrastructure Patterns

[[List any infrastructure design patterns utilized in this solution. Provide links to common patterns as applicable.]

New Infrastructure

[Describe the infrastructure design to support the solution.]

Logical Design

[Provide a visual representation of the infrastructure logical design.]

Figure 10 – Infrastructure Logical Design Diagram

Infrastructure Environments

[Depict the infrastructure physical design to support the solution. If any environments are combined or not part of the solution, change this section accordingly.]

Development

[Provide a visual representation of the physical development environment.]

Figure 11 – Development Environment Diagram

Test

[Provide a visual representation of the physical test environment.]

Figure 12 – Test Environment Diagram

QA

[Provide a visual representation of the physical QA environment.]

Figure 13 – QA Environment Diagram

Production

[Provide a visual representation of the physical production environment.]

Figure 14 – Production Environment Diagram

Disaster Recovery (DR)

[Provide a visual representation of the physical DR environment.]

Figure 15 – Production Environment Diagram

Infrastructure Catalog

Development

Specifications
Number of servers:	1
Description:	VM Host Server
Name:	VMSERV
Model:	Dell PowerEdge r815
CPU:	4 X 8 = 32 cores
RAM:	128 GB
Network:	Gigabit
OS:	VMware ESXi 4.1
DB:
Storage:
Supp Apps:
Applications:
Peripherals:
Comments:

Test

Specifications
Number of servers:
Description:
Name:
Model:
CPU:
RAM:
Network:
OS:
DB:
Storage:
Supp Apps:
Applications:
Peripherals:
Comments:

QA

Specifications
Number of servers:
Description:
Name:
Model:
CPU:
RAM:
Network:
OS:
DB:
Storage:
Supp Apps:
Applications:
Peripherals:
Comments:

Production

Specifications
Number of servers:
Description:
Name:
Model:
CPU:
RAM:
Network:
OS:
DB:
Storage:
Supp Apps:
Applications:
Peripherals:
Comments:

Disaster Recovery (DR)

Specifications
Number of servers:
Description:
Name:
Model:
CPU:
RAM:
Network:
OS:
DB:
Storage:
Supp Apps:
Applications:
Peripherals:
Comments:

Production Support

[This chapter specifies components, processes and procedures required to maintain and support the solution on an ongoing basis.]

Point of Failure Analysis

[Identify any specific components and/or processes that will impact the daily operation of the solution.]

System Reliability

[Identify any specific considerations for achieving reliable operation of the solution. If none, enter N/A.]

System Monitoring

[Identify any specific components and/or processes that will be put in place to detect degradation and/or failure of the operational aspects of the solution.]

System Recovery

[Describe the strategy to be deployed for recovering from non-disastrous operational failure of the solution.]

Disaster Recovery

[Describe the strategy to be deployed to recover from disastrous events and meeting the Recover Time Objective (RTO) and Recovery Point Objective (RPO).for the solution.]

Portability

[Identify any specific considerations for providing portability of the solution]

Support and Maintenance

[This section identifies the departments and teams that will be responsible for supporting the logical and physical components of the solution. For every logical node, components material to the design should be listed and the supporting group be identified. Any support process that is not already defined is considered “New”.]

Development

Logical Node	Component	Support Team	New
Application Server	OS / HW Platform
MS .Net Framework
Application
Database Server	OS / HW Platform
MS .Net Framework
MS SQL Server
Web Server	OS / HW Platform
MS .Net Framework
MS IIS

Test / QA

Logical Node	Component	Support Team	New
Application Server	OS / HW Platform
MS .Net Framework
Application
Database Server	OS / HW Platform
MS .Net Framework
MS SQL Server
Web Server	OS / HW Platform
MS .Net Framework
MS IIS

Production & Disaster Recovery (DR)

Logical Node	Component	Support Team	New
Application Server	OS / HW Platform
MS .Net Framework
Application
Database Server	OS / HW Platform
MS .Net Framework
MS SQL Server
Web Server	OS / HW Platform
MS .Net Framework
MS IIS

Appendix

[Placeholder for any supporting documents, tables, charts, diagrams etc. that are referenced but not contained in the main body of the document.]